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REMARKS 

Favorable reconsideration of this application in light of the preceding 
amendments and the following discussion is respectfully requested. 

No claims having been added or canceled by this response. Applicants 
respectfully submit that claims 1-7, 9-18, 20-26, 29, 31-48, 51 and 53-56 remain pending 
and properly under consideration in this application. Applicants submit that the above 
Listing of Claims shows the amended claims in marked-up form in accordance with 37 
C.F.R. § 1.121. Applicants submit that the amendment to claim 35 is intended to correct 
a typographical error that resulted in the deletion of the subject from the dependent 
clause. 

Rejections under 35 U,S,C. S 103 

Claims 1-7, 9-18, 20-26, 29, 31-48, 51 and 53-56 stand rejected under 35 U.S.C. 
103(a) as unpatentable over So's U.S. Pub. Pat. Appl. No. 2002/0109879 Al ("So") in 
view of Enoki et al.'s U.S. Pub. Pat. Appl. No. 2002/0057691 Al ("Enoki"). Applicants 
traverse this rejection. 

Applicants note that the Examiner again cites So's paragraphs [0194], [0365], 
[0488] and [0572] for allegedly teaching each of the claimed elements with the exception 
of having the device itself generate a backward path request message. Applicants 
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respectfully incorporate the discussion provided in their response of December 1, 2007, 
with regard to the deficiencies noted in So's disclosure. 

Turning to the secondary reference, Applicants submit that Enoki does not 
remedy the deficiencies previously identified in So. hiitially, Applicants note that the 
cited portion of Enoki provides only that "the LSR 3 transmits a label request message 
S26 required for the down direction LSP setup . . . Action at 3 (citing Enoki 
para. [0147] (emphasis added). Applicants submit that those of ordinary skill in the art 
recognize a distinction between the act of generating and the act of transmitting. Indeed, 
Applicants contend that the cited portion of Enoki simply duplicates the disclosure 
provided in So that provided: 

[0 1 94] The construction of a bi-directional lightpath differs from the 
construction of a uni-directional lightpath above only in that upon 
receiving the setup request, the last-hop router returns the setup message 
using the reverse of the explicit route of the forward path. Both 
directions of a bi-directional lightpath share the same characteristics^ 
e.g., set of nodes, bandwidth and restoration requirements. For more 
general bi-directional connectivity, a user simply requests multiple 
individual lightpaths. 

So, para. [0194] (emphasis added). Applicants contend that Enoki, like So, provides for a 
terminal device capable of transmitting a backward path based on the "bidirectional 
setup" information received fi"om LSR 1 , but that there has been no showing that Enoki 
teaches or suggests that the "LSR 3" router is capable of independently ("by itself) 
generating a backward path. Enoki provides: 
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[0143] It is to be noted that FIG. 15 shows a sequence of the bidirectional 
LSP setup message in the embodiment (2). In case an external request S20 
of setting up 1 Mbps LSP between the terminals "A" and "B" is made to 
the LSR 1 5 the LSR 1 transmits a label request message S21 in which the 
bidirectional setup and the down direction (from terminal ^^B'^ to ^^A 
bandwidth designation of 1 Mbps are set in the vendor-private TLV to the 
LSR 2. 

[0144] The LSR 2 which has received the message S21 transmits the label 
request message S22 similar to the message S21 to the LSR 3. 

[0145] The LSR 3 performs the process for the bidirectional LSP setup 
based on the vendor-private TLV within the label request message S22. 
At this time, the LSR 3 stores the correspondence of the bidirectional LSP 
ID'S and performs a dovm direction LSP setup S23 with the designated 
bandwidth (1 Mbps). 

Enoki, paras. [0143]-[0145] (emphasis added). 

Applicants contend, therefore, that one of ordinary skill in the art would 
understand that Enoki, like So, teaches that the down direction information is provided to 
the device from external (downstream) sources. Accordingly, in both So and Enoki, the 
characteristics of the "backward" or "down direction" path are defined by the "setup 
request" received from LSR 1 without any modification or independent action by the 

■ 

receiving unit in defining the "down direction" parameters. Applicants fiirther note that 
this understanding of Enoki is reinforced by Enoki 's characterization of the invention as 
comprising: 



. . . a bidirectional LSP setup accepting portion for accepting an external 
bidirectional LSP setup request^ a bidirectional LSP setup TLV preparing 
portion for preparing a bidirectional LSP setup TLV included in a 
bidirectional setup label request message transmitted in an up direction 
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to a label switching router placed at another end of the LSP based on the 
bidirectional LSP setup request, a bidirectional LSP setup TLV analyzer 
for analyzing the bidirectional LSP setup TLV in the message when the 
message is received from the label switching router at the other end, a 
bidirectional LSP processor for performing an LSP setup request in a 
down direction as opposed to the up direction based on the analyzed 
result by the bidirectional LSP setup TLV analyzer, and an explicit route 
preparing portion for preparing an explicit route on which a router to be 
relayed in the down direction is prescribed, based on an explicit route 
preparing request from the bidirectional LSP processor, based on the 
CRLDP, and for notifying the prepared route to the bidirectional LSP 
processor. 

Enoki, para. [0034] (emphasis added). 

Applicants note that, as amended, claim 1 requires that the network device be 
operable in a manner that whereby the device can: 

. . . independently generate and send a backward path request message to a 
source of a separately generated, initial forward path request message 
associated with a forward Label Switched Path (LSP) between the device 
and the source .... (emphasis added) 

Applicants further contend that the cited portions of Enoki cannot fairly be characterized 
as providing for the "independent" generation of the "backward path" as recited in the 
pending claims. Indeed, with respect to backward path generation, Enoki's "LSR 3" 
router may be more fairly characterized as a "slave" unit that merely utilizes the routing 
information from the received bidirectional setup. 

Applicants contend, therefore, that the proposed combination of So and Enoki 
references are not sufficient to teach or suggest each element of the pending claims as 
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required for a rejection under 35 U.S.C. § 103. Furthermore, Applicants contend that one 
of ordinary skill in the art relying on the So and Enoki references would not be led to the 
functional modifications necessary to achieve the claimed inventions. 

With respect to claim 2, the Examiner suggest that So's paragraphs [0374], 
specifically lines 4-6, and [0482], specifically lines 1-3, teach the additional elements 
recited in claim 2. Applicants note that these paragraphs provide in their entirety: 

[0374] At a conceptual level, explicit LSPs and optical channel trails 
exhibit certain commonalities. Essentially, they are both fundamentally 
unidirectional, point-to-point virtual path connection abstractions. An 
explicit LSP provides a parameterized packet forwarding path (traffic- 
trunk) between an ingress LSR and an egress LSR. Correspondingly, an 
optical channel trail provides a (possibly parameterized) optical channel 
between two endpoints for the transport of client digital signals. The 
payload carried by both LSPs and optical trails are transparent to 
intermediate nodes along their respective paths. Both LSPs and optical 
trails can be parameterized to stipulate their performance, behavioral, and 
survivability requirements fi"om the network. 

and 

[0482] Using the concept of nested LSPs (with a label stack) allows the 
system to scale by building a forwarding hierarchy. At the top of this 
hierarchy are FSC interfaces, followed by LSC interfaces, followed by 
TDM interfaces, followed by PSC interfaces. This way, an LSP that starts 
and ends on a PSC interface can be nested (together with other LSPs) into 
an LSP that starts and ends on a TDM interface. This LSP, in turn, can be 
nested (together with other LSPs) into an LSP that starts and ends on a 
LSC interface, which in tum can be nested (together with other LSPs) into 
an LSP that starts and ends on a FSC interface. 

Action at 3 (emphasis added). Applicants submit that the cited portions of the So 
reference cannot fairly be characterized as teaching a device capable of generating and 
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sending an "initial, forward path reservation message to the source in order to establish 
the forward LSP after receiving the initial forward path request message." Applicants 
suggest that the cited portions of the So reference do not provide any basis for 
determining where, within the system, the "initial forward path reservation message" is 
generated. Indeed, as detailed above, Applicants contend that, as taught by So, it is the 
initial request from the "source" that provides the information for the forward path rather 
than path information generated in the receiving or "last-hop router." 

With regard to claims 3 and 4, Applicants incorporate the discussion above 
regarding the teachings of the So and Enoki references. Applicants contend that the 
discussion provided, Action at 3-4, muddles the source/device/destination distinction 
among the system components. Applicants request, therefore, that the next 
communication from the Office provide a substantive explanation as to how the cited 
portions of the reference are being interpreted to support the present rejection. In 
particular. Applicants again contend that while the cited paragraphs of the So reference 
provide: 

[0194] The construction of a bi-directional lightpath differs from the 
construction of a uni-directional lightpath above only in that upon 
receiving the setup request, the last-hop router returns the setup message 
using the reverse of the explicit route of the forward path. Both 
directions of a bi-directional lightpath share the same characteristics , 
e.g., set of nodes, bandwidth and restoration requirements. For more 
general bi-directional connectivity, a user simply requests multiple 
individual lightpaths. 

J|C J|C 9t( 
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[0365] The functions of the control plane (for both LSRs and OXCs) 
include resource discovery, distributed routing control, and connection 
management. In particular, the control plane of the LSR is used to 
discover, distribute, and maintain relevant state information associated 
with the MPLS network, and to instantiate and maintain label switched 
paths (LSPs) under various MPLS traffic engineering rules and policies. 
An LSP is the path through one or more LSRs followed by a specific 
forwarding equivalence class (FEC). An explicit LSP is one whose route is 
defined at its origination node. 

* * * 

[0488] While traditional traffic engineered MPLS (and even LDP) are 
unidirectional^ generalized MPLS supports the establishment of bi- 
directional LSPs, see Section 4. The need for bi-directional LSPs come 
from non-PSC applications. There are multiple reasons why such LSPs 
are needed, particularly possible resource contention when allocating 
reciprocal LSPs via separate signaling sessions, and simplifying failure 
restoration procedures in the non-PSC case. Bi-directional LSPs also have 
the benefit of lower setup latency and lower number of messages required 
during setup. Other features supported by generalized MPLS are rapid 
failure notification, see Section 5, and termination of an LSP on a specific 
egress node, see Section 6. 

So, paras. [0194], [0365] and [0488] (emphasis added). Applicants contend that there is 
no indication or suggestion in the cited portions as to which components of the system 
are generating and receiving the various routing-related messages or the content of those 
messages. Applicants contend that absent such specificity, speculation as to the content of 
those messages is not sufficient to support the present rejection. 

With regard to claims 5 and 6, Applicants contend that focusing on the 
correspondence of the forward and backward paths fails to address the manner in which 
those paths are generated. Applicants contend, therefore, that the discussion above with 
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regard to the manner in which the So reference generates the respective paths is equally 
applicable to claims 5 and 6. 

With regard to claim 7, Applicants incorporate the discussion above with regard 
to the generation and content of the various messages transmitted among the system 
components for the purposes of establishing forward and backward LSPs. Again, 
Applicants contend that, as taught by So, the backward path routing is provided in the 
forward path request and is not, therefore, independently generated by the device. 

With regard to claims 9-18 and 20-22, Applicants contend that these claims' 
dependence from claim 1 is sufficient to distinguish them from the teachings of So. 

With regard to claim 12, Applicants further contend that the cited paragraph: 

[0320] Random fluctuations in the location of rising and falling edges of 
bits relative to a local or recovered clock reference. As line speeds 
continue to increase, jitter will become a critical performance parameter. 

So, para. [0320], does not teach or suggest a QoS indicator. Action at 5. Accordingly, 
Applicants contend that the present rejection is not properly supported by the cited 
portions of the applied reference and that the rejection should be withdrawn. 

With regard to claim 13, Applicants further contend that the cited paragraphs: 

[0230] End-to-end restoration is proposed for all-optical networks or sub- 
networks. If no wavelength conversion is used in the network and on the 
client/network interface, then the same wavelength will be required for the 
primary and restoration lightpaths if the client cannot retune its 
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wavelength on failure. Whether or not the client can provide this re-tuning 
can be passed as a parameter in the lightpath request. 

[023 1 ] Wavelength selection on the primary and restoration lightpaths 
should be simultaneously performed if the same wavelength is required on 
both of these lightpaths. This requires that the wavelengths available on 
both of the lightpaths to be returned to the first-hop router and a decision 
made before either lightpath is established. It also requires that specific 
wavelengths be reserved for restoration at each node, significantly 
increasing the state information required. The issue becomes even more 
complex in a hybrid transparent and opaque OXC environment. However, 
we believe that we should focus on opaque OXC environment on the first 
phase while keeping in mind that in the future it may be required to 
incorporate transparent and mixed optical networks. 

So, paras. [0230] and [0231], Action at 5, do not suggest that any such request originates 
the claimed network device. Accordingly, Applicants contend that the present rejection 
is not properly supported by the cited portions of the applied reference and that the 
rejection should be withdrawn. 

With respect to claim 14, Applicants further contend that the cited paragraph: 

[0615] (b) Lightpath deletion: This action allows an existing lightpath 
(referenced by its ID) to be deleted, (c) Lightpath modification: This 
action allows certain parameters of the lightpath (referenced by its ID) to 
be modified. Lightpatii modification may be subject to network-defined 
policies. Lightpath modification must be non-destructive, e.g., the success 
or failure of the modification procedure must not result in the loss of the 
original lightpath. 

So, para. [0615], Action at 5-6, does not teach or suggest that the network device, rather 
than the source, initiates the lightpath deletion. Accordingly, Applicants contend that the 
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present rejection is not properly supported by the cited portions of the applied reference 
and that the rejection should be withdrawn. 

With respect to claims 1 5 and 1 6, Applicants further contend that the cited 
paragraphs: 

[0570] For bi-directional LSPs, two labels must be allocated. Bi- 
directional LSP setup is indicated by the presence of an Upstream Label in 
the REQUEST/Path message. An Upstream Label has the same format as 
the Generalized Label, see Section 3.2. In RSVP the Upstream Label uses 
a new class number (TBD of form Obbbbbbb) and the C-type of the label 
being suggested. In CR-LDP, Upstream Label uses type=0x0906. 

a|E % 

[0572] The process of establishing a bi-directional LSP follows the 
establishment of a unidirectional LSP with some additions. To support bi- 
directional LSPs an Upstream Label is added to the Path/REQUEST 
message. The Upstream Label MUST indicate a label that is valid for 
forwarding at the time the Path/REQUEST message is sent. When a 
Path/REQUEST message containing an Upstream Label is received, the 
receiver first verifies that the upstream label is acceptable. If the label is 
not acceptable, the receiver MUST issue a PathErr/NfOTIFICATION 
message with a "Routing problem/Unacceptable label value" indication. 
An intermediate node must also allocate a label on the outgoing interface 
and establish internal data paths before filling in an outgoing Upstream 
Label and propagating the Path/REQUEST message. If an intermediate 
node is unable to allocate a label or internal resources, then it MUST issue 
a PathErr/NOTIFICATION message with a "Routing problem/Label 
allocation failure" indication. Terminator nodes process Path/REQUEST 
messages as usual, with the exception that the upstream label can 
immediately be used to transport associated data upstream to the initiator. 
When a bi-directional LSP is removed, both upstream and downstream 
labels are invalidated and it is no longer valid to send data using the 
associated labels. 
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So, paras. [0570] and [0572] do not teach or suggest that the claimed network device is 
"operable to send the first delete path message . . Action at 6. Accordingly, 
Applicants contend that the present rejection is not properly supported by the cited 
portions of the applied reference and that the rejection should be withdrawn. 

With respect to claims 17,18 and 20-22, Applicants incorporate the discussion 
above with regard to the "generation" function attributed to the cited portions of the 
Enoki reference. In particular. Applicants maintain that the "bidirectional LSP setup 
message" provides the information for the LSP to the node and that there is no teaching 
or suggestion of independent "generation" of path data at the network device in response 
to a backward path request or other message from the destination. 

With regard to claims 23-26, 29, 3 1-48, 5 1 and 53-56, Applicants incorporate the 
discussion above with respect to the applicability of So and Enoki to the preceding claims 
and contend that the method and means claims are allowable for at least the same 
reasons. In particular. Applicants contend that the cited portions of the So and Enoki 
references do not clearly support the associated contention(s) with regard to the teachings 
as vmderstood by one of ordinary skill in the art. Applicants maintain, therefore, that until 
some substantive explanation is provided as to exactly how the cited text supports the 
pending rejection, Applicants have not been afforded a full and fair opportunity to 
understand and address the Examiner's technical interpretation and reasoning. 
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Applicants request that the pending rejections be reconsidered and withdrawn 



accordingly. 



CONCLUSION 



In view of the above remarks and amendments, Applicants respectfully submit 
that each of the pending objections and rejections have been addressed and overcome, 
leaving the present application in condition for allowance. A Notice to that effect is 
respectfully requested. 

If the Examiner believes that personal communication will expedite prosecution 
of this application, the Examiner is invited to contact the xmdersigned. 

If necessary, the Commissioner is hereby authorized in this, concurrent, and 
future replies to charge any underpayment or non-payment of any fees required under 37 
C.F.R. §§ 1.16 or 1.17, or credit any overpayment of such fees, to Deposit Account 
No. 503777, including, in particular, extension of time fees. 



Respectfully submitted, 



Capitol Patent & Trademark Law Firm, PLLC 




John E. Curtin, Reg. No. 37,602 



P.O. Box 1995 
Vienna, V A 22183 
JEC/GPB 
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